Protocol message compression in a wireless communications system

ABSTRACT

A method, apparatus, system, and computer software for compressing and decompressing a message for transmission. The method of compressing a text message for transmission may include parsing text strings and encoding numerical values with a binary representation and analyzing values of the text strings and populating a session specific codebook with partial strings from the values. The method of compressing a message for transmission may also include parsing the message with a template and generating at least one substring to be transmitted; parsing the at least one substring with entries in a session specific codebook and generating a first part of the compressed message; populating the session specific codebook with entries for unknown field values; parsing any unmatched substrings with entries from a first static dictionary and generating a second part of the compressed message; parsing any still unmatched substrings with entries from a second static dictionary and generating a third part of the compressed message; compressing a remainder of the substrings with a compression algorithm; and combining the first part, the second part, and the third part of the compressed message to obtain a compressed message for transmission.

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is related to a concurrently filed applicationby Chuah et al., entitled “Binary Protocol For Session Initiation in aWireless Communications System”, the entire contents of which are herebyincorporated by reference.

BACKGROUND OF THE INVENTION

[0002] 1. Field of the Invention

[0003] This invention relates to communications and, more particularly,to protocol message compression for a wireless communications system.

[0004] 2. Description of Related Art

[0005] Two communication technologies are commonly used by the generalpublic; cellular telephony and the Internet. Cellular telephony providesits users with the freedom of mobility—the possibility of being reachedwith reasonable service quality regardless of location. However, themain service provided by cellular telephony is speech. While flexibilityfor all kinds of usage (speech, data, video, audio, etc.) has beenInternet's strength, its focus has been on fixed connections andrelatively large terminals, and the quality of some services (such asInternet telephony) has generally been poor. As technology advances, theInternet and cellular technologies are merging. Future cellular “phones”may contain an IP-stack (internet protocol) and support voice over IP inaddition to web-browsing, e-mail, etc. In essence, the Internet is goingmobile, or cellular systems are becoming much more than telephony,depending on the point of view.

[0006]FIG. 1 shows a conventional network 10 which can be divided into aradio access network (RAN) 12 and a core network (CN) 14. The RAN 12comprises the equipment used to support wireless interfaces 16 a-bbetween a wireless unit 18 a-b and the network 10. The RAN 12 includesNodeBs or base stations 20 a-c connected over links (Iub links) 21 a-cto radio network or base station controllers (RNC) 22 a-b. The interfacebetween the base station and the RNC is referred to as the Iub interfaceor link, and the interface between two RNCs is referred to as the Iurinterface. Currently, both the Iub and Iur interfaces are based on ATM(a synchronous transfer mode), and ATM switches are allowed betweenNodeBs and RNCs.

[0007] The core network 14 includes the network elements that supportcircuit-based communications as well as packet-based communications. Inestablishing a circuit channel to handle circuit-based communicationsbetween the wireless unit 18 b and a public switched telephone network(PSTN) 24 or another wireless unit, the base station 20 b receives (inthe uplink) and transmits (in the downlink), the coded information(circuit voice or circuit switched data) over the wireless interface orlink 16 b. The RNC 22 b is responsible for frame selection, encryptionand handling of access network mobility. The RNC 22 b forwards thecircuit voice and circuit switched data over a network, such as anATM/IP network to a 3G mobile switching center (MSC) 30. The 3G-MSC 30is responsible for call processing and macromobility on the MSC level.The 3G-MSC 30 establishes the connectivity between the wireless unit 18b and the PSTN 24.

[0008] Commonly used terms in this technical field are “all-IP” and “IPall the way”. These terms both relate to the case where an IP is usedend to end, even if the path involves cellular links, and IP is also runover the radio hop(s). This is done for all types of traffic, both theuser data (e.g. voice or streaming) and control signaling data, eitherSIP (session initiation protocol) or RTSP (real time streamingprotocol). A benefit of this is the service flexibility introduced by IPcombined with the freedom provided by continuous mobility. The downsideis the relative large overhead the IP protocol suite typicallyintroduces, e.g. due to large headers and text-based signalingprotocols.

[0009] In cellular systems, the scarce radio resources should be used inan efficient way. It should be possible to support a sufficient numberof users per cell, otherwise costs will be prohibitive. Frequencyspectrum and thus bandwidth are costly resources in cellular links andshould be used carefully.

[0010] The ROHC (RObust Header Compression) working group hassuccessfully solved the problem of reducing bandwidth requirements forthe header parts of real time protocol (RTP), user datagram protocol(UDP), and IP packets. With this obstacle removed, new possibilities ofenhancing mobile internet performance arise. One of these relates toapplication signaling protocols. Protocols such as SIP, RTSP, and SDP(session description protocol) are typically used to set up and controlapplications in a mobile Internet. However, the protocol messages arelarge in size and create delays due to their request/response nature.Compression of these messages would increase spectrum efficiency andreduce transmission delay.

[0011] The SIP is an application layer protocol for establishing,modifying and terminating multimedia sessions or calls. These sessionsinclude Internet multimedia conferences, Internet telephony and similarapplications. SIP can be used over either TCP (Transmission ControlProtocol) or UDP. SIP is a text based protocol, using ISO 10646 in UTF-8encoding.

[0012] The SDP may be used to advertise multimedia conferences andcommunicate conference addresses and conference tool-specificinformation. The SDP is also used for general real-time multimediasession description purposes. SDP is carried in the message body of SIPand RTSP messages. SDP is text based using the ISO 10646 character setin UTF-8 encoding.

[0013] The RTSP is an application level protocol for controllingdelivery of data with real-time properties, such as audio and video.RTSP may use UDP or TCP (or another protocol) as the transport protocol.RTSP is text based using the ISO 10646 character set in UTF-8 encoding.

[0014] The above protocols have many similarities. These similaritieshave implications on solutions to the problems they create inconjunction with the cellular radio access. Their similarities includethe following:

[0015] Requests and reply characteristics. When a sender sends arequest, it stays idle until it has received a response, hence, ittypically takes a number of round trip times to conclude a SIP, SDP, orRTSP session.

[0016] They are ASCII based. Thus to represent the value 230, 3*8=24bits are used. A binary representation of the same value, by comparison,would require only 8 bits.

[0017] They are large in size in order to provide the necessaryinformation to the session participants.

[0018] SIP and RTSP share many common header field names, methods andstatus codes. Their traffic patterns are also similar. The signaling iscarried out primarily during the setup phase. For SIP, this means thatthe majority of the signaling is carried out to set up a phone call ormultimedia session. For RTSP, the majority of the signaling is donebefore the transmission of application data.

[0019] The need for solving the problems caused by the signalingprotocol messages is made clear by looking at a typical SIP/SDP CallSetup sequence over a narrow band cellular channel and by studyingresults from a simple system capacity example. These results indicatethat there also would be a gain to the system capacity by reducing thesize of the single protocol messages.

[0020]FIG. 2 illustrates an example of SIP signaling between twotermination points with a wireless link between, and the resulting delayunder certain system assumptions.

[0021] The one way delay is calculated according to the followingequation:

OneWayDelay=MessageSize[in bits]/LinkSpeed[in bits/sec]+RTT[in sec]/2  Eq. (1)

[0022] where RTT is the round trip time.

[0023] The following values have been used: RTT/2:  70 msec LinkSpeed9.6 kbps

[0024] The delay formula in Eq. (1) is based on an approximation of aWCDMA (wideband code division multiple access) radio access method forspeech services. For instance, delays caused by possible retransmissionsdue to errors are ignored.

[0025] Applying Eq. (1) to each SIP/SDP message shown in the example ofFIG. 2 gives a total delay of 4130 msec from the first SIP/SDP messageto the last. The RSVP and Session Management (Radio Bearer setup),displayed in FIG. 2 will add approximately 1.5 seconds to the totaldelay, using Eq. (1). However, there may also be RSVP and SM signalingprior to the SIP INVITE message to establish the radio bearer, whichwould add approximately another 1.5 seconds.

[0026] The TSG (Technical Specification Group) has performed acomparison between a GSM (Global System for Mobiles) Edge (Enhanced DataRates for Global Evolution) Radio Access Network (GERAN) call setupusing SIP and an ordinary GSM call setup. For a typical GSM call setup,the time is about 3.6 seconds, and for the case when using SIP, the callsetup is approximately 7.9 seconds.

[0027] A first solution to decrease the call setup using SIP uses adynamic dictionary and the LZSS (Lempel-Ziv-Storer-Szymanski)compression algorithm. The dynamic dictionary is kept as long as packetsbelonging to the context keep arriving. Determining whether a packetflow is still active can be done using a timer or from the semantics ofthe protocol. This solution introduces 2 bytes of overhead for everycompressed message.

[0028] In this first solution, compression includes the followingssteps:

[0029] 1. Append the message to the dictionary and compress the extendedfile using LZSS.

[0030] 2. Separate the part of the compressed file that corresponds tothe dictionary from the part which corresponds to the message. This ispossible since LZSS processes the file from left to right and the partwhich has already been compressed does not change as the compressionproceeds. That is, compressing the dictionary itself or compressing itwith a message appended to it will produce the same output (apart fromthe compressed message).

[0031] In this first solution, decompression includes the followingsteps:

[0032] 1. Append the compressed message to the compressed dictionary anddecompress the extended file.

[0033] 2. Separate the message from the dictionary. This is possiblebecause the boundry of the dictionary is known and the message isappended to the dictionary.

[0034] The performance of this first solution is as follows. The firstmessage compression ratio is 1.5 and subsequent message compressionratios range from 3.1 to 8.3 depending on the operation modes of thecompressor and decompressor. In a limited contact mode, the decompressorcan acknowledge messages from the compressor, so that the compressor canmake sure that the decompressor has the same dictionary as thecompressor. In a full contact mode, the compressor and decompressor areone entity and share the dictionary, so both sent and received messagescan be used for the compression process.

[0035] A second solution uses LZJH (Lempel-Ziv-Jeff-Heath) as thecompression algorithm. This second solution uses preloaded dictionaryand a multi-packet mode, where the dictionary is updated using previousmessages, and then using the LZJH compression algorithm. This secondsolution can reduce the first message by a ratio of 2.8.

[0036] In summary, when SIP messages are compressed individually using aLempel-Ziv-type algorithm, the compression ratio is around 1.5. With apreloaded static dictionary, most conventional compression algorithmsyield a compression ration of less than 3 for SIP messages. When acodebook is populated by the first INVITE message, Lempel-Ziv-typealgorithms improve the compression ratio to close to 5.

[0037] Thus, a better solution is needed to further reduce signalingdelay and required bandwidth when considering both system bandwidthrequirements and service setup delays.

SUMMARY OF THE INVENTION

[0038] The present invention is directed to message compression thatshortens the call setup time by using multi-packet compressionalgorithms to compress the messages.

[0039] The present invention is also directed to a method, apparatus,system, and software for performing protocol message compression in awireless communication system. The present invention utilizes acompression algorithm that combines binary coding, templates, sessionspecific codebooks, and/or conventional Lempel-Ziv-based algorithms. Thepresent invention also utilizes a message ID, the binary encoding ofsome fields, such as a service provider address, a caller user ID, acaller user name, a callee user ID, and a callee user name, and utilizesIPv4 format for domain names. The present invention also enables binarycoding of numerical values for some fields. The present invention alsoprovides a session specific codebook, a modified indexing mechanism,codebook management, and session history. Still further, the presentinvention provides a flexible template with fixed and variable lengthsub-fields, as well as a flexible template with optional fields. Stillfurther, the present invention provides general purpose lossless textcompression. In an exemplary embodiment, the present invention achievesbetter compression through the use of a session specific codebook and anoptional dictionary at the SIP server/media duplicator. Binary encodingof numerical fields also helps reduce the size of IP addresses, callerIDs, session IDs, etc. The present invention also includes a flexibletemplate structure and permits the use of fixed lengths for selectedtemplate fields and encodes variable length field with either lengthindicators or delimiters. The present invention also permits optionalfields to be inserted into templates to reduce the total number oftemplates that need to be stored in memory.

[0040] In one exemplary embodiment, the present invention is directed toa method of compressing a text message for transmission comprisingparsing text strings and encoding numerical values with the binaryrepresentation and analyzing values of the text string and populating asession specific codebook with partial strings from the values. Inanother exemplary embodiment, the present invention is directed to amethod of compressing a message for transmission, comprising parsing themessage with a template and generating at least one substring to betransmitted; parsing the at least one substring with entries in asession specific codebook and generating a first part of the compressedmessage; populating the session specific codebook with entries forunknown field values; parsing any unmatched substrings with entries froma first static dictionary and generating a second part of the compressedmessage; parsing any still unmatched substrings with entries from asecond static dictionary and generating a third part of the compressedmessage; compressing a remainder of the substrings with a compressionalgorithm; and combining the first part, the second part, and the thirdpart of the compressed message to obtain a compressed message fortransmission.

BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Other aspects and advantages of the present invention may becomeapparent upon reading the following detailed description and uponreference to the drawings in which:

[0042]FIG. 1 shows a general block diagram of a conventional networkarchitecture.

[0043]FIG. 2 shows a SIP signaling delays assuming a link speed of 9600bps and an RTT of 140 msec.

[0044]FIG. 3 illustrates an exemplary architecture for performingcompression in one exemplary embodiment of the present invention.

[0045]FIG. 4 illustrates an exemplary message compression framework inone exemplary embodiment of the present invention.

[0046]FIG. 5 illustrates template-based coding, in one exemplaryembodiment of the present invention.

[0047]FIG. 6 illustrates an example of user A completing a call user B,in one exemplary embodiment of the present invention.

[0048]FIG. 7 illustrates compression results achieved in one exemplaryembodiment of the present invention.

DETAILED DESCRIPTION

[0049]FIG. 3 illustrates the environment in which thecompression/decompression of SIP messages of the present invention maybe performed. As illustrated in FIG. 3, two entities 10, 12 areseparated by a physical channel 14. Each entity 10, 12 includes aphysical layer 16, and IP layer 18, a UDP/TCP layer 20, thecompression/decompression layer 22 of the present invention, and an SIPlayer 24.

[0050]FIG. 4 illustrates a message compression framework in oneexemplary of the present invention. Within the compression/decompressionlayer 22, entities 10 and 12 include a compressor 100, a codebook 102,and a decompressor 104, through which original messages 106, compressedmessages 108, and decompressed messages 110 are passed.

[0051] As illustrated in FIG. 2, the compression mechanism of thepresent invention serves as the layer 22 between the SIP applications 24and the UDP and/or TCP 20. The purpose of compression is to reduce thetotal amount of data across the physical channel 14, thus reduce thedelay.

[0052] Compression algorithms work well with a priori information of theoriginal message. SIP messages within a session share many commoninformation such the user addresses and port numbers.

[0053] SIP messages have many repeated headers which can be easilycompressed. Compression algorithms can work with either preloadeddictionaries, dynamic dictionaries or templates. An exemplary staticdictionary for SIP messages is shown below.

[0054] In the exemplary static dictionary:

[0055] Needed spaces are indicated with <sp>

[0056] Needed carriage returns are indicated with <cr>

[0057] Needed line feeds are indicated with <lf>

[0058] All other possible spaces, carriage returns, line feeds etc,should be disregarded when using is exemplary static dictionary.

[0059] <Start of static Dictionary>

[0060]INVITE<sp>sip:<sp>SIP/2.0<cr><lf>Via:<sp>SIP/2.0/UDP<sp>:5060<cr><lf>

[0061] From:<sp>To:<sp>Call-ID:<sp>CSeq:<sp>1<sp>INVITE<cr><lf>

[0062] Contact:<sp>Content-Type:<sp>application/sdp<cr><lf>

[0063] Content-Length:<sp>0<cr><If>SIP/2.0<sp>100<sp>Trying<cr><lf>

[0064] SIP/2.0<sp>180<sp>Ringing<cr><lf>SIP/2.0<sp>200<sp>OK<cr><lf>

[0065] SIP/2.0<sp>181<sp>Call<sp>Is<sp>Being<sp>Forwarded<cr><lf>

[0066]SIP/2.0<sp>182<sp>Queued<cr><If>SIP/2.0<sp>183<sp>Session<sp>Progress<cr><lf>

[0067] PRACK<sp>sip:COMET<sp>sip:ACK<sp>sip:BYE<sp>sip:Accept:<sp>Accept-Encoding:<sp>Accept-Language:<sp>Allow:<sp>Authorization:<sp>

[0068] Content-Encoding:<sp>Content-Length:<sp>Encryption:<sp>

[0069] Expires:<sp>Hide:<sp>Contact:<sp>Max-Forwards:<sp>

[0070] Proxy-Authenticate:<sp>Proxy-Authorization:<sp>Proxy-Require:<sp>

[0071] Require:<sp>Response<sp>Key:<sp>Route:<sp>Timestamp:<sp>

[0072]Unsupported:<sp>User-Agent:<sp>WWW-Authenticate:<sp>Supported:<sp>

[0073] Remote-Party-ID:<sp>Proxy-Require:<sp>Anonymity:<sp>

[0074] <End of static dictionary>

[0075] A template is a table of orderly strings. Compared withdictionaries, fixed header information does not need to be transmitted,thus further reducing the message size. For each type of messages, adefault template can be defined. The following is an example oftemplate-based coding.

[0076]FIG. 5 is an example of template-based encoding. The template hasa template ID (TID), four static fields (ss0, ss2, ss4, and ss6), andthree blank fields (b1, b3, and b5). It is assumed that all blank fieldshave variable lengths. For simplicity, the filling sub-strings (ss1,ss3, and ss5) are encoded in the form of <length, value>. Again forsimplicity, it is assumed that the value is the uncompressed form of theoriginal sub-string.

[0077] When compared with dictionary-based compression, template-basedcompression can achieve a higher compression efficiency, as the positionand length information of the static parts have already been stored in atemplate, and do not need to be transferred.

[0078] Templates can be defined for each type of messages. When thenumber of templates grows, the memory associated with templates may be aconcern. Alternatively, an additional field can be inserted into atemplate. A header ID (HID) can be assigned to each header. Then theadditional field can be inserted into the compressed string as<HID|Lx|ssx> at the desired position.

[0079] As shown in previous studies, compression ratio of the firstINVITE message is not significant even with a template-based approach.Since there exists knowledge about the contents of SIP/SDP fields, it ispossible to improve the compression performance over general compressionalgorithms such as Lempel-Ziv-type compression algorithms.

[0080] An optional static dictionary can be used for some selected SIPfield values. This dictionary could include typical SDP values, such as“IN IP4” for the <network type> <address type> fields of a typicalinternet sessions. Most UID's (user identifications) can be representedby 4 bytes. A service provider typically has less than 256 millionsubscribers, hence, the 4 most significant bits can be used to representa service provider identifier and the remaining bits to represent ausername. When a numerical value is expected in a field, a binaryrepresentation can be used.

[0081] The compression method, in one exemplary embodiment of thepresent invention, can be summarized as follows:

[0082] 1) Parse the message with a matching template and generate thesubstrings that need to be transmitted.

[0083] 2) Parse the substrings with a session specific codebook(initialized to empty) and generate part of the compressed message.

[0084] 3) Populate the session specific codebook with unknown fieldvalues.

[0085] 4) Parse the unmatched substrings with a static dictionary andgenerate part of the compressed message.

[0086] 5) Parse the unmatched substrings with the optional staticdictionary and output part of the compressed message.

[0087] 6) Compress the rest of the substrings with LZSS.

[0088] 7) Combine the outputs of steps 2) and 4)-6) as the finalcompressed message.

[0089] It is noted that some substrings in a template can be assigned adefault length after compression, which will reduce one byte for eachfield. A predefined escape character may be used to flag the lengthchange.

[0090] The exemplary compression algorithm outlined above is applied toseveral examples below, where a successful simple SIP to SIP call isestablished, as illustrated in FIG. 6.

EXAMPLE 1

[0091] Message Details

[0092] F1 INVITE User A→User B

[0093] INVITE sip:UserB@there.com SIP/2.0

[0094] Via: SIP/2.0/UDP here.com:5060

[0095] From: BigGuy<sip:UserA@here.com>

[0096] To: LittleGuy<sip:UserB@there.com>

[0097] Call-ID: 12345601@here.com

[0098] CSeq: 1 INVITE

[0099] Contact: <sip:UserA@100.101.102.103>

[0100] Content-Type: application/sdp

[0101] Content-Length: 147

[0102] v=0

[0103] o=UserA 2890844526 2890844526 IN IP4 here.com

[0104] s=Session SDP

[0105] c=IN IP4 100.101.102.103

[0106] t=0 0

[0107] m=audio 49172 RTP/AVP 0

[0108] a=rtpmap:0 PCMU/8000

[0109] Applying step 1, the message is parsed with a matching templateand the substrings that need to be transmitted are generated. In Example1, The result of step 1 is as follows:

[0110] Template ID: TID

[0111] UserB@there.com

[0112] here.com:5060

[0113] BigGuy UserA@here.com

[0114] LittleGuy UserB@there.com

[0115] 12345601 (“@here.com” is assumed to be the same as above)

[0116] 1 INVITE

[0117] <100.101.102.103>(“sip:UserA@” is assumed to be the same asabove) (“application/sdp” assumed to be the same)

[0118] 147

[0119] 2890844526 (“UserA” “IN IP4 here.com” taken from above,“2890844526”, the version of the annoucement is the same timestamp assession id)

[0120] 100.101.102.103

[0121] 49172 (“audio” “RTP/AVP 0”)

[0122] rtpmap:0 PCMU/8000.

[0123] Removing comments, the resulting substrings are:

[0124] TID

[0125] UserB@there.com

[0126] here.com

[0127] BigGuy UserA@here.com

[0128] LittleGuy UserB@there.com

[0129] 12345601

[0130] 1 INVITE

[0131] 100.101.102.103

[0132] 147

[0133] 2890844526

[0134] 100.101.102.103

[0135] 49172

[0136] rtpmap:0 PCMU/8000.

[0137] Applying step 2, the substrings are parsed with a sessionspecific codebook (initialized to empty) to generate part of thecompressed message. Since the session specific codebook is empty, nooutput is generated.

[0138] Applying step 3, the session specific codebook is populated withunknown field values. The resulting session specific codebook will beused for compression of subsequent messages. In Example 1, the resultingsession specific codebook is as shown in Table 1. TABLE 1 Header EntryIndex UserB@there.com Via: here.com user address UserA@here.comUserB@there.com address_of_record BigGuy UserA@here.com LittleGuyUserB@there.com Call-ID 12345601 Contact 100.101.102.103m 49172 RTP/AVP0 A rtpmap:0 PCMU/8000

[0139] It is noted in Table 1, that each header is not limited to havingone entry. Further, not all unknown fields are used to populate thecodebook because some may not repeat, such as the announcement number inSDP. The session specific codebook can then be used tocompress/decompress subsequent messages of the same session. It is notedthat codebook management may be helpful. For example, when a match withthe entry is found, one byte is used to indicate the header in thesession profile, and another byte is used to specify which entry ismatched for the header.

[0140] Applying step 4, the unmatched substrings are parsed with astandard static dictionary, such as the one shown above, and part of thecompressed message is generated. In Example 1, since all headers andmany constant values are included in the template, no additional outputare generated by parsing through the standard static dictionary.

[0141] Applying step 5, unmatched substrings are parsed with the staticdictionary and part of the compressed message is output. TABLE 2Original Strings Compression UserB@there.com match “there.com” 1 bytehere.com 1 byte BigGuy UserA@here.com 4 bytes LittleGuy UserB@there.commatch “there.com” 1 or 0 bytes 12345601 8 bytes 1 INVITE 2 bytes100.101.102.103 4 bytes 147 1 byte 2890844526 8 bytes 100.101.102.103 4or 0 bytes 49172 2 bytes rtpmap:0 PCMU/8000 1 byte

[0142] In Example 1, the result of step 5 is 37 or 32 bytes:

[0143] It is noted that all domain names may be stored in the optionalstatic dictionary at all SIP entities. In Example 1, 1 byte is assignedfor each domain name. At the same time, a 4 byte user address may beassigned to the transmitting SIP entity when the device is initialized.

[0144] Applying step 6, the rest of the substrings are compressed withan exemplary compression algorithm, such as LZSS.

[0145] The TID can be represented with 1 byte. The user id (the stringbefore ‘@’ in the user address) is 5 bytes long and the user name(LittleGuy) is 10 bytes long. In Example 1, at most 16 bytes will begenerated after LZSS compression.

[0146] Applying step 7, the outputs of steps 2 and 4-6 are combined asthe final compressed message. This results in 37 or 32 bytes plus the 16generated after LZSS compression.

[0147] 37+16=53 bytes.

[0148] or 32+16=48 bytes,

[0149] which is a compression ratio of=423/53=8.0; 423/48=8.8.

[0150] The following examples describe the steps for subsequentmessages.

EXAMPLE 2

[0151] Message Details

[0152] F2 (100 Trying) User B→User A

[0153] SIP/2.0 100 Trying

[0154] Via: SIP/2.0/UDP here.com:5060

[0155] From: BigGuy<sip:UserA@here.com>

[0156] To: LittleGuy<sip:UserB@there.com>

[0157] Call-ID: 12345601@here.com

[0158] CSeq: 1 INVITE

[0159] Content-Length: 0

[0160] After decoding message F1 from Example 1, User B has populatedthe codebook with the content of the INVITE message.

[0161] Applying step 1 to Example 2, the following substrings aregenerated:

[0162] TID

[0163] here.com

[0164] BigGuy UserA@here.com

[0165] LittleGuy UserB@there.com

[0166] 12345601

[0167] 1 INVITE

[0168] 0

[0169] Applying step 2 to Example 2, the substrings are parsed with asession specific codebook, as shown in Table 3. TABLE 3 Original StringsCompression TID no match here.com 2 bytes BigGuy UserA@here.com 2 bytesLittleGuy UserB@there.com 2 bytes 12345601 2 bytes 1 INVITE no match 0no match

[0170] A subtotal of 8 bytes are obtained.

[0171] Assuming that the algorithm is in a full contact mode, where thecompressor and decompressor share the codebook 102, after UserAtransmits the compressed INVITE message, the decompressor 104 at UserAcan also access the session specific codebook. When the INVITE messageis received by UserB, it populates its session specific codebook, whichwill be identical to that at UserA. Hence, when the message (100 trying)is compressed and decompressed, the session specific codebook can beused.

[0172] Applying step 3, the session specific codebook is populated. Inthis Example, there are no new strings.

[0173] Applying step 4, the standard static dictionary reveals nomatches, which results in a second subtotal of 0 bytes.

[0174] Applying step 5, the optional static dictionary is parsed,producing Table 4, which results in a third subtotal of 3 bytes. TABLE 4Original Strings Compression TID no match 1 INVITE 2 bytes 0 1 byte

[0175] Applying the step 6, the rest of the substrings is compressedwith LZSS or other exemplary compression algorithm.

[0176] TID is a one byte template index, which results in a fourthsubtotal of 1 byte.

[0177] Applying step 7, the outputs are combined to produce

[0178] 8+0+3+1=12 bytes,

[0179] which is a compression ratio of 187/12 15.6.

EXAMPLE 3

[0180] Message Details

[0181] F3 180 Ringing User B->User A

[0182] SIP/2.0 180 Ringing

[0183] Via: SIP/2.0/UDP here.com:5060

[0184] From: BigGuy<sip:UserA@here.com>

[0185] To: LittleGuy<sip:UserB@there.com>

[0186] Call-ID: 12345601@here.com

[0187] CSeq: 1 INVITE

[0188] Content-Length: 0

[0189] Apply the same procedure as above for Example 2, the resultingmessage is 12 bytes, and the compression ratio is 187/12=15.6.

EXAMPLE 4

[0190] Message Details

[0191] F4 200 OK User B→User A

[0192] SIP/2.0 200 OK

[0193] Via: SIP/2.0/UDP here.com:5060

[0194] From: BigGuy<sip:UserA@here.com>

[0195] To: LittleGuy<sip:UserB@there.com>

[0196] Call-ID: 12345601@here.com

[0197] CSeq: 1 INVITE

[0198] Contact: <sip:UserB@110.111.112.113>

[0199] Content-Type: application/sdp

[0200] Content-Length: 147

[0201] v=0

[0202] o=UserB 2890844527 2890844527 IN IP4 there.com

[0203] s=Session SDP

[0204] c=IN IP4 110.111.112.113

[0205] t=0 0

[0206] m=audio 3456 RTP/AVP 0

[0207] a=rtpmap:0 PCMU/8000

[0208] Applying step 1 to Example 4, the following substrings aregenerated:

[0209] TID

[0210] UserB@there.com

[0211] here.com

[0212] BigGuy UserA@here.com

[0213] LittleGuy UserB@there.com

[0214] 12345601

[0215] 1 INVITE

[0216] 110.111.112.113

[0217] 147

[0218] 2890844527

[0219] 110.111.112.113

[0220] 3456

[0221] rtpmap:0 PCMU/8000

[0222] Applying step 2 to Example 4, the substrings are parsed with thesession specific codebook as shown in Table 5, which results in a firstsubtotal of 16 bytes: TABLE 5 Original Strings Compression TID no matchUserB@there.com 2 bytes here.com 2 bytes BigGuy UserA@here.com 2 bytesLittleGuy UserB@there.com 2 bytes 12345601 2 bytes 1 INVITE 2 bytes110.111.112.113 no match 147 2 bytes 2890844527 no match 110.111.112.113no match 3456 no match rtpmap:0 PCMU/8000 2 bytes

[0223] Applying the step 3 to Example 4, the session specific codebookis populated as shown in Table 6: TABLE 6 Header Entry IndexUserB@there.com Via here.com user address UserA@here.com UserB@there.comaddress_of_record BigGuy UserA@here.com LittleGuy UserB@there.comCall-ID 12345601 Contact 100.101.102.103 110.111.112.113 M 49172 3456 Artpmap:0 PCMU/8000

[0224] Applying step 4 to Example 4, no match is found in the staticdictionary, which results in a second subtotal of 0 bytes.

[0225] Applying step 5 to Example 4, reveals several matches as shownbelow in Table 7, which results in a third subtotal of 14 bytes. TABLE 7Original Strings Compression TID no match 110.111.112.113 4 bytes2890844527 8 bytes 110.111.112.113 0 (same as above) 3456 2 bytes

[0226] Applying step 6 to Example 4, the rest of the substring, a onebyte template index for the TID, is compressed with LZSS to produceanother 1 byte subtotal.

[0227] Combining the outputs for Example 4 gives

[0228] 16+14+1=31 bytes, which is a compression ratio: 403/31=13.

EXAMPLE 5

[0229] Message Details

[0230] F5 ACK User A→User B

[0231] ACK sip:UserB@there.com SIP/2.0

[0232] Via: SIP/2.0/UDP here.com:5060

[0233] From: BigGuy<sip:UserA@here.com>

[0234] To: LittleGuy<sip:UserB@there.com>

[0235] Call-ID: 12345601@here.com

[0236] CSeq: 1 ACK

[0237] Content-Length: 0

[0238] Applying the same procedure as above for Example 2, the resultingmessage is 12 bytes, and the compression ratio is 197/12=16.4.

EXAMPLE 6

[0239] Message Details

[0240] F6 BYE User B→User A

[0241] BYE sip:UserA@here.com SIP/2.0

[0242] Via: SIP/2.0/UDP there.com:5060

[0243] From: LittleGuy<sip:UserB@there.com>

[0244] To: BigGuy<sip:UserA@here.com>

[0245] CSeq: 1 BYE

[0246] Content-Length: 0

[0247] Applying step 1 to Example 6, the following substrings aregenerated:

[0248] TID

[0249] UserA@here.com

[0250] there.com

[0251] LittleGuy UserB@there.com

[0252] BigGuy UserA@here.com

[0253] 12345601

[0254] 1 BYE

[0255] 0

[0256] Applying step 2 to Example 6, the substrings are parsed with thesession specific codebook, as shown in Table 8, which results in a firstsubtotal of 10 bytes. TABLE 8 Original Strings Compression TID no matchUserA@here.com 2 bytes there.com 2 bytes BigGuy UserA@here.com 2 bytesLittleGuy UserB@there.com 2 bytes 12345601 2 bytes 1 Bye no match 0 nomatch

[0257] Applying step 3 to Example 6, the session specific codebook ispopulated as shown in Table 9. TABLE 9 Header Entry IndexUserB@there.com UserA@here.com Via here.com there.com user addressUserA@here.com UserB@there.com aaddress_of_record BigGuy UserA@here.comLittleGuy UserB@there.com Call-ID 12345601 Contact 100.101.102.103 M49172 3456 A rtpmap:0 PCMUY8000

[0258] Applying step 4 to Example 6, the standard static dictionaryreveals no matches which results in a second subtotal of 0 bytes.

[0259] Applying step 5 to Example 6, the optional static dictionary isparsed, producing Table 10, which results in a third subtotal of 4bytes. TABLE 10 Original Strings Compression TID no match there.com 1byte 1 Bye 2 bytes 0 1 byte

[0260] Applying step 6 to Example 6, the rest of the substrings arecompressed, a one byte template index for the TID, with LZSS to produceanother 1 byte subtotal.

[0261] Combining the outputs for Example 6 gives 10+4+1=15 bytes, whichis a compression ratio: 197/15=13.1.

EXAMPLE 7

[0262] Message Details

[0263] F7 200 OK User A→User B

[0264] SIP/2.0 200 OK

[0265] Via: SIP/2.0/UDP there.com:5060

[0266] From: LittleGuy <sip:UserB@there.com>

[0267] To: BigGuy <sip:UserA@here.com>

[0268] Call-ID: 12345601@here.com

[0269] CSeq: 1 BYE

[0270] Content-Length: 0

[0271] Applying the same procedure as above for Example 2, the resultingmessage is 12 bytes, and the compression ratio is 181/12=15.1.

[0272]FIG. 7 illustrates compression ratios achieved by the method ofthe present invention for other messages.

[0273] In summary, in previous studies using session specific codebooks,the codebook is populated with the fields in the messages as is and isindexed with the “From” field. In exemplary embodiments of the presentinvention, the field values are analyzed in addition to the whole fieldand keywords are extracted. As a result, the codebook of the presentinvention generates more matches with only a moderate increase inmemory.

[0274] Further, previous studies, direct table lookup for the useraddresses has been avoided because of the large memory requirement andlong search time. Still further, a domain names lookup table is storedin the optional static dictionary at all SIP entities. Since the numberof service providers that provide push-and-talk service is very limited,1 byte can be assigned for each domain name.

[0275] In a Push-to-talk service, the SIP server/Proxy server/redirectserver is located on the network side, which is presumed to be powerfulenough to conduct a full user address search. Thus, a 4 bytes binary IDis assigned to each user address. This 4 byte ID is also assigned toeach SIP entity when the device is initialized. Hence, in the INVITEmessage, a mobile device can simply replace it's address with this 4byte ID.

[0276] Still further, although the present invention has been describedin conjunction with compression, one of ordinary skill in the art wouldappreciate the decompression steps are inverse to the compression stepsdescribed above.

[0277] The present invention could also implement an inter-sessiondictionary feature. If a device is programmed to store recent useraddress history in memory, further reduction of the INVITE message forlater sessions can be expected. In addition, for those who buy groupservices, service providers can provide a small lookup table that mapsuser address with 4-byte binary ID. With this approach, compression ofuser address (by using the 4-byte binary ID) can take place even for thefirst INVITE message.

[0278] The present invention utilizes a compression algorithm thatcombines binary coding, templates, session specific codebook and/orconventional Lempel-Ziv algorithms. The resulting compressed SIPmessages are approximately {fraction (1/10)} in size compared with theoriginal messages.

[0279] As set forth above, one or more reasons for this gain is a resultof one or more of the features of the present invention described above.These features include the use of a message ID, the binary encoding ofselective fields, such as the service provider address, the caller userID, the caller user name, the callee user ID name, and the calleE username, and an IPV4 format for domain names. These features also includethe binary encoding of selected numerical values, the use of a sessionspecific codebook, and a modified indexing mechanism. Still further,these features include codebook management and session history. Stillfurther, these features include a flexible template with fixed andvariable length fields as well as a flexible template with optionalfields. One or more combinations of the above features are effective inproviding general purpose lossless text compression.

[0280] Further as described above, each SIP entity contains both acompressor 100 and decompressor 104. Thus, information could be sharedbetween the compressor 100 and decompressor 104 to further reduce themessage sizes.

[0281] Although the above-identified examples have been described in thecontext of SIP protocol messages, these examples are equally applicableto SDP, RTSP or any other known or later developed protocol.

[0282] Still further, although the features of the present inventionhave been described above in the context of a method, these features arealso applicable to apparatus, system, and software applications, andembodying the teachings of the present application in an apparatus,system, or software would be achievable by one of ordinary skill in theart.

[0283] What has been described is merely illustrative of the applicationof the principles of the present invention. Those skilled in the artwill readily recognize that these and various other modifications,arrangements and methods can be made to the present invention withoutstrictly following the exemplary applications illustrated and describedherein and without departing from the spirit and scope of the presentinvention.

We claim:
 1. A method of compressing a text message for transmission,comprising: parsing text strings and encoding numerical values with abinary representation; and analyzing values of the text strings andpopulating a session specific codebook with partial strings from thevalues.
 2. The method of compressing a text message of claim 1, whereinthe text strings include domain names and the domain names are replacedwith IP addresses.
 3. The method of compressing a text message of claim2, wherein the IP addresses are encoded with binary representation. 4.The method of compressing a text message of claim 1, wherein the textmessage is parsed with a template.
 5. The method of compressing amessage of claim 4, wherein a different template is provided for eachtype of message.
 6. The method of compressing a message of claim 4,wherein the template includes optional fields so that the template isusable for multiple message types.
 7. The method of compressing a textmessage of claim 1, wherein the partial strings are parsed with entriesin the session specific codebook.
 8. The method of compressing a messageof claim 1, wherein the session specific codebook is empty for the firsttext message compressed for transmission and entries are added as eachmessage is compressed.
 9. The method of compressing a message of claim1, wherein the session specific codebook includes one or more entriesfor each header type.
 10. The method of compressing a text message ofclaim 1, wherein the partial strings are parsed with a staticdictionary.
 11. The method of compressing a text message of claim 10,wherein the static dictionary is initialized with user specificinformation.
 12. The method of compressing a text message of claim 10,wherein the static dictionary is initialized with past session history.13. The method of compressing a text message of claim 1, wherein thepartial strings not matched in the session specific codebook or thestatic dictionary are compressed with a compression algorithm.
 14. Themethod of compressing a message of claim 13, wherein the compressionalgorithm is a Lempel-Ziv-based compression algorithm.
 15. The method ofcompressing a message of claim 14, wherein the Lempel-Ziv-basedcompression algorithm is the Lempel-Ziv-Storer-Szymanski algorithm. 16.The method of compressing a message of claim 1, wherein the compressedmessage for transmission is an session initiation protocol (SIP),session description protocol (SDP), or realtime streamlining protocol(RTSP) message (RTSP).
 17. A method of compressing a message fortransmission, comprising: parsing the message with a template andgenerating at least one substring to be transmitted; parsing the atleast one substring with entries in a session specific codebook andgenerating a first part of the compressed message; populating thesession specific codebook with entries for unknown field values; parsingany unmatched substrings with entries from a first static dictionary andgenerating a second part of the compressed message; parsing any stillunmatched substrings with entries from a second static dictionary andgenerating a third part of the compressed message; compressing aremainder of the substrings with a compression algorithm; and combiningthe first part, the second part, and the third part of the compressedmessage to obtain a compressed message for transmission.
 18. The methodof compressing a message of claim 17, wherein a different template isprovided is for each type of message.
 19. The method of compressing amessage of claim 17, wherein fields are added the template so that thetemplate is usable for multiple message types.
 20. The method ofcompressing a message of claim 17, wherein the session specific codebookis empty for the first compressed message and entries are added as eachmessage is compressed.
 21. The method of compressing a message of claim17, wherein the one or more of the entries of the first staticdictionary and the second static dictionary are binary encoded.
 22. Themethod of compressing a message of claim 17, wherein the sessionspecific codebook includes one or more entries for each header type. 23.The method of compressing a message of claim 17, wherein the firststatic dictionary and the second static dictionary include compressionvalues previously encountered substrings.
 24. The method of compressinga message of claim 17, wherein the first static dictionary and thesecond static dictionary are a single static dictionary.
 25. The methodof compressing a message of claim 17, wherein the compression algorithmis a Lempel-Ziv-type compression algorithm.
 26. The method ofcompressing a message of claim 25, wherein the Lempel-Ziv-typecompression algorithm is the Lempel-Ziv-Storer-Szymanski algorithm. 27.The method of compressing a message of claim 17, wherein the compressedmessage for transmission is an session initiation protocol (SIP),session description protocol (SDP), or realtime streamlining protocol(RTSP) message (RTSP).